Postgres MVCC 原理

前言

前面介紹了樂觀鎖的原理，這裡將介紹在 postgres 中，是如何利用樂觀鎖的原理來建構 MVCC DB 的。

CRUD在MVCC下的長相

我們先建立好一張table叫table1，裡面只有name這個欄位。

CREATE TABLE table1 (
	"name" varchar NOT NULL
);

remark: 以下範例使用 PostgreSQL 12.3

隱藏欄位

其實 Postgres 每個表中都有一些隱藏欄位，
我們可以嘗是在任何一張 table query 出那些欄位

select ctid,xmin,xmax,cmin,cmax,id from XXX_TABLE

ctid: 可以幫我們看一下是否有新的 record 建立出來
xmin: 看該筆 record 是由哪個 tx 所建立的，這裡填上 txId
xmax: 看該筆 record 是由哪個 tx 所刪除的，這裡填上 txId
cmin：插入事務中的命令標識符（從 0 開始）
cmax：刪除交易中的命令標識符（從 0 開始）

後續的介紹我們這裡只需要特別注意ctid與xmax,xmin這三個key即可。

我們知道每次的操作都是一個 transaction，那麼該如何得知目前的 transactionId 呢？
可以下
select txid_current()

大概知道上面各個欄位做什麼後，接下來開始解析 CRUD 的操作會有什麼變化吧！

CREATE

先來看看insert後會有什麼變化

begin;
SELECT txid_current(); --735
insert into table1 (name) values ('a' );
select *,ctid,xmin,xmax from table1;
commit;

READ

begin;
select *,ctid,xmin,xmax from table1;
commit;

DELETE

--tx1
begin;
SELECT txid_current(); --754
DELETE FROM table1 WHERE name = 'a';

因為delete commit後就無法利用一般的select查到，
所以我們趁著還沒commit之前，開另外一個tx來做select。

--tx2
select *,ctid,xmin,xmax from table1;

可以看到xmax被賦予了值，而xmax就是DELETE資料的txid。

UPDATE

--tx1
begin;
SELECT txid_current(); --755
UPDATE  table1 set name='uu' where name='a';
select *,ctid,xmin,xmax from table1;

因為UPDATE commit後就無法利用一般的select查被標誌上delete的紀錄，
我們趁著還沒commit之前，開tx2來做select。

--tx2
select *,ctid,xmin,xmax from table1;

所以update的動作我們可以被視為:
insert一筆新紀錄+delete一筆舊紀錄。

Remark: 如果兩個tx同時update，後面update的會需要等前面tx的commit完後才能做update。

ROLLBACK

至於rollback呢?
我們就拿剛剛還沒COMMIT的UPDATE來做ROLLBACK.
然後再select *,ctid,xmin,xmax from table1;

ctid(0,1)雖然沒有被刪除掉也仍然可以被查看，但是他的xmax居然還有755的標記，這是什麼原因呢?我們先繼續往下看。

我們再新增一筆紀錄
insert into table1 (name) values ('b');

rollback沒看到ctid(0,2)很合理，但是ctid(0,1)的xmax被填上了755，所以他到底是被刪除了還是還沒呢?
這時就要討論一下postgres MVCC的可見性判斷了。

可見性判斷

邏輯大概是這樣
每個有做過write的tx都會有一個自己的txid.
而如果只有xmin代表新增的紀錄,如果同時有xmin與xmax代表被刪除的紀錄.
每一筆的紀錄，在操作時，都會被記錄到一個clog的檔案之中，
用來表示該筆紀錄是否有被其他tx正在做修改。

clog (commit log)

在每個tx的執行之中，都會在每筆紀錄clog，來表示該表紀錄正處於什麼樣的狀態之中。
#define TRANSACTION_STATUS_IN_PROGRESS=0x00 正在進行中
#define TRANSACTION_STATUS_COMMITTED=0x01 已提交(commit)
#define TRANSACTION_STATUS_ABORTED=0x02 已回滾(rollback)
#define TRANSACTION_STATUS_SUB_COMMITTED=0x03 子事務已提交

判斷邏輯

主要會先判斷clog，

1. TRANSACTION_STATUS_IN_PROGRESS，如果xmin與xmax不是自己的txid那麼就不可見。
2. TRANSACTION_STATUS_COMMITTED，進入下一個判斷。
   1. txid>xmin or xmax:代表舊有的tx，該是什麼樣就什麼樣。
   2. txid=xmin or xmax:代表目前自己操作的tx，該是什麼樣就什麼樣。
   3. txid<xmin or xmax:代表未來的tx，不可見。
3. TRANSACTION_STATUS_ABORTED，進入下一個判斷。
   1. txid>xmin or xmax:代表舊有的tx，該是什麼樣就不要什麼樣。
   2. txid=xmin or xmax:代表目前自己操作的tx，該是什麼樣就不要什麼樣。
   3. txid<xmin or xmax:代表未來的tx,不可見。
      而剛剛

的clog這兩筆紀錄被標註上了TRANSACTION_STATUS_ABORTED，
因此，代表著被新增的要不可見，被刪除的要可見。

結語

postgres 透過 xmin/xmax 與 commit 的狀態來判斷是否為該 tx 可以用的資料。
我們可看到當 rollback 與刪除時，這些標記都還在，頻繁操作的表會累積大量標記，佔用硬碟空間，
postgres 的解決方法是提供 vacuum 命令來清理過期的數據，也會在後續的單元中介紹。

參考資料

1. PostgreSQL 的 MVCC 机制解析
2. PostgreSQL Commit Log(clog)
3. PostgreSQL 中的 MVCC (01)——基本可见性判断
4. PostgreSQL MVCC可见性判断